Anyone looking at this ticket now would assume that there is something wrong with it as several automatic checks have failed. But none of the failures have (as far as I can see) anything to do with the new eclib. I myself am not going to take any further action on this unless someone tells me that I am wrong about this.

This requires patching sagelib due to API changes. See https://gitlab.archlinux.org/archlinux/packaging/packages/sagemath/-/blob/main/eclib-20241112.patch?ref_type=heads

This requires patching sagelib due to API changes. See https://gitlab.archlinux.org/archlinux/packaging/packages/sagemath/-/blob/main/eclib-20241112.patch?ref_type=heads

Thanks. I will make the changes you suggest in the link and update the PR.

Documentation preview for this PR (built with commit 893e20e; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

The forced push was just after rebasing on current develop.

As usual I have no idea what is making any of the failures, this time I am more confident that it is nothing to do with this PR but whi knows? I hope someone does.

Only had a quick look but at least the build failures for "Build & Test using Meson" are in the files changed in this PR. I suppose the problem is that these changes are not backwards compatible. Could you make compile sage with both the old and new version of eclib? If not, I'm afraid this PR has to wait until the new version is available on conda.

Only had a quick look but at least the build failures for "Build & Test using Meson" are in the files changed in this PR. I suppose the problem is that these changes are not backwards compatible. Could you make compile sage with both the old and new version of eclib? If not, I'm afraid this PR has to wait until the new version is available on conda.

Thanks for the explanation. I had thought, apparently wrongly, that the code in spkg-configure.m4 which checks for the existence of an installed eclib version which is new enough was there precisely to deal with this situation. If you are building Sage in an environment where only a too-old eclib is available, then the build process will build its own version of eclib. No? That certainly used to be the case. If not, then I don't see how any upstream developer (e.g. me for eclib) can ever reliably upgrade their library for Sage.

If one uses conda, then all of sage-the-distro (everything under the build folder) is ignored, see https://doc.sagemath.org/html/en/installation/conda.html#using-conda-to-provide-all-dependencies-for-the-sage-library

Is it really not possible to support both the old and new version of ecm in sage?

If one uses conda, then all of sage-the-distro (everything under the build folder) is ignored, see https://doc.sagemath.org/html/en/installation/conda.html#using-conda-to-provide-all-dependencies-for-the-sage-library

Is it really not possible to support both the old and new version of ecm in sage?

(eclib not ecm)

I will try -- there are very few lines which had to be different in the wrapping code.

If one uses conda, then all of sage-the-distro (everything under the build folder) is ignored, see https://doc.sagemath.org/html/en/installation/conda.html#using-conda-to-provide-all-dependencies-for-the-sage-library
Is it really not possible to support both the old and new version of ecm in sage?

(eclib not ecm)

I will try -- there are very few lines which had to be different in the wrapping code.

OK, I can do away with the get_entries() methods which used to return a scalar* and now return a vector[scalar], and use the methods which deliver individual entries.

Incidentally, I would be amazed if there was anyone in the world who actually use this part of eclib in Sage: it is the conversion to a Sage matric f an eclib matrix, as returned by the Hecke operator functions on a CremonaModularSymbols space.

I will update the interface code and update this PR.

OK, I rebased on current develop and made a few changes to the interface so that neither scalar* nor vector[scalar] are used. I hope this is enough.

I checked the logs for failing tests and the only one is in src/sage/libs/gap/element.pyx which is not relevant to this PR, I think. In particular, it was happy with the tests in src/sage/libs/eclib.

still needs a rebase

If someone tells me what is now wrong and how to fix it, and if it is anything to do with my latest attempt to upgrade eclib (which used to be easy enough for me to do) then I will fix it.

lgtm

Segfaults on 32-bit:

sage: E = EllipticCurve('11a') ## line 1454 ##
sage: phi = E.pollack_stevens_modular_symbol() ## line 1455 ##
------------------------------------------------------------------------
/var/lib/buildbot/worker/sage_git/build/local/var/lib/sage/venv-python3.12.5/lib/python3.12/site-packages/cysignals/signals.cpython-312-i386-linux-gnu.so(+0x8372)[0xf680a372]
/var/lib/buildbot/worker/sage_git/build/local/var/lib/sage/venv-python3.12.5/lib/python3.12/site-packages/cysignals/signals.cpython-312-i386-linux-gnu.so(+0x840f)[0xf680a40f]
/var/lib/buildbot/worker/sage_git/build/local/var/lib/sage/venv-python3.12.5/lib/python3.12/site-packages/cysignals/signals.cpython-312-i386-linux-gnu.so(+0xb354)[0xf680d354]
linux-gate.so.1(__kernel_sigreturn+0x0)[0xf7f5c570]
/var/lib/buildbot/worker/sage_git/build/local/lib/libec.so.14(_Z12gauss_reducellllRlS_S_S_+0xda)[0xa4504a5a]
/var/lib/buildbot/worker/sage_git/build/local/lib/libec.so.14(_Z10new_modratllRlS_+0x42)[0xa4504c52]
/var/lib/buildbot/worker/sage_git/build/local/lib/libec.so.14(_Z6modratllRlS_+0x24)[0xa4504cf4]
/var/lib/buildbot/worker/sage_git/build/local/lib/libec.so.14(_Z6modratiiRiS_+0x26)[0xa4504d26]
/var/lib/buildbot/worker/sage_git/build/local/lib/libec.so.14(_Z4liftRK5vec_iRKiRS_+0x2c0)[0xa4525b20]
/var/lib/buildbot/worker/sage_git/build/local/lib/libec.so.14(_Z4liftRK5vec_i+0x41)[0xa4581d01]
/var/lib/buildbot/worker/sage_git/build/local/lib/libec.so.14(_ZN12form_finder211make_basis2ER7ff_dataRK5vec_i+0xd1)[0xa4581ed1]
/var/lib/buildbot/worker/sage_git/build/local/lib/libec.so.14(_ZN12form_finder210make_basisER7ff_data+0x409)[0xa4582399]
/var/lib/buildbot/worker/sage_git/build/local/lib/libec.so.14(_ZN12form_finder28splitoffERKSt6vectorIlSaIlEE+0x386)[0xa4584246]
/var/lib/buildbot/worker/sage_git/build/local/lib/libec.so.14(_ZN12form_finder27recoverESt6vectorIS0_IlSaIlEESaIS2_EE+0x64)[0xa45845c4]
/var/lib/buildbot/worker/sage_git/build/local/lib/libec.so.14(_ZN8newforms16createfromcurvesEiSt6vectorI8CurveRedSaIS1_EEi+0x531)[0xa46dcb01]
/var/lib/buildbot/worker/sage_git/build/local/lib/libec.so.14(_ZN8newforms15createfromcurveEiRK8CurveRedi+0xd7)[0xa46dcf47]
/var/lib/buildbot/worker/sage_git/build/src/sage/libs/eclib/newforms.cpython-312-i386-linux-gnu.so(+0xba36)[0xa479ba36]
/var/lib/buildbot/worker/sage_git/build/local/var/lib/sage/venv-python3.12.5/lib/libpython3.12.so.1.0(+0x12da60)[0xf7ae7a60]
/var/lib/buildbot/worker/sage_git/build/local/var/lib/sage/venv-python3.12.5/lib/libpython3.12.so.1.0(_PyObject_MakeTpCall+0x9c)[0xf7a7ef2c]
/var/lib/buildbot/worker/sage_git/build/local/var/lib/sage/venv-python3.12.5/lib/libpython3.12.so.1.0(PyObject_Vectorcall+0x74)[0xf7a7f264]
/var/lib/buildbot/worker/sage_git/build/local/var/lib/sage/venv-python3.12.5/lib/libpython3.12.so.1.0(_PyEval_EvalFrameDefault+0x5025)[0xf7a29cf5]
/var/lib/buildbot/worker/sage_git/build/local/var/lib/sage/venv-python3.12.5/lib/libpython3.12.so.1.0(+0x1b7311)[0xf7b71311]

See: JohnCremona/eclib#81 (comment)

A new version of modrat() has been introduced, and it seems to have issues with overflow. Definitely for 32 bit, and maybe only for 32 bit, but in the end I just reverted to old_modrat() with https://github.com/tornaria/void-packages/blob/pari/srcpkgs/eclib/patches/fix-32bit-modrat.patch.

Edit: I copy here the patch, since the url above is gone.

--- a/libsrc/arith.cc
+++ b/libsrc/arith.cc
@@ -429,8 +430,8 @@ int new_modrat(long n, long m, long& a, long& b);
 
 int modrat(long n, long m, long& a, long& b)
 {
-  // return old_modrat(n, m, a, b);
-  return new_modrat(n, m, a, b);
+  return old_modrat(n, m, a, b);
+  //return new_modrat(n, m, a, b);
 }
 
 int old_modrat(long n, long m, long& a, long& b)

@tornaria How about using one of the methods given in https://stackoverflow.com/questions/1505582/determining-32-vs-64-bit-in-c to choose which method to use? In fact it might be worth setting a macro in one place (such as interface.h) which can then be checked elsewhere. There's an issue about whether this should be done at compile time or run time. Since the function modrat() is used a lot it would be best to decide at compile time, and that appears to rely on having the right headers to define the correct macros.

@tornaria How about using one of the methods given in https://stackoverflow.com/questions/1505582/determining-32-vs-64-bit-in-c to choose which method to use? In fact it might be worth setting a macro in one place (such as interface.h) which can then be checked elsewhere. There's an issue about whether this should be done at compile time or run time. Since the function modrat() is used a lot it would be best to decide at compile time, and that appears to rely on having the right headers to define the correct macros.

Are you sure this is an issue about 32-bit vs. 64-bit, or is this a bug that is just easier to trigger on 32-bit?

Well, I am certain that it is possible to trigger crashes on 64-bit machines -- I do not check that whenever I multiply two long ints that the product fits into a long int!

I have a plan to replace all my integer arithmetic with FLINT integers, but that will take a long time and be very tedious. At the same time I would use FLINT for all floating point. I don't see an easy way of doing this incrementally, so I am not very enthusiastic about starting!

Well, I am certain that it is possible to trigger crashes on 64-bit machines -- I do not check that whenever I multiply two long ints that the product fits into a long int!

I have a plan to replace all my integer arithmetic with FLINT integers, but that will take a long time and be very tedious. At the same time I would use FLINT for all floating point. I don't see an easy way of doing this incrementally, so I am not very enthusiastic about starting!

Sure, if you are going to replace arithmetic, it may not be worth fixing modrat now. Note that flint has rational reconstruction, it even special cases the 1 limb case https://github.com/flintlib/flint/blob/main/src/fmpq/reconstruct_fmpz_2.c#L258

The trick there is doing the gaussian reduction on the first row instead of the norm. This avoids the arithmetic on integers of double the size. Of course, you can't go all the way of the gcd or you would obtain a rational number of the form 1/K, but you can stop as in the half-gcd (i.e. the first time a is small enough). This is probably a win for bigints also, since it avoids doing the arithmetic with integers larger than the input size.

Well, I am certain that it is possible to trigger crashes on 64-bit machines -- I do not check that whenever I multiply two long ints that the product fits into a long int!

I have a plan to replace all my integer arithmetic with FLINT integers, but that will take a long time and be very tedious. At the same time I would use FLINT for all floating point. I don't see an easy way of doing this incrementally, so I am not very enthusiastic about starting!

IMHO rather than moving between concrete implementations of integers, one should have templated code which allows plugging in whatever available integers (or, horror, algebraic numbers?)

Well, I am certain that it is possible to trigger crashes on 64-bit machines -- I do not check that whenever I multiply two long ints that the product fits into a long int!
I have a plan to replace all my integer arithmetic with FLINT integers, but that will take a long time and be very tedious. At the same time I would use FLINT for all floating point. I don't see an easy way of doing this incrementally, so I am not very enthusiastic about starting!

IMHO rather than moving between concrete implementations of integers, one should have templated code which allows plugging in whatever available integers (or, horror, algebraic numbers?)

Good point -- in fact eclib does this for its vector, matrix and sparse matrix classes. Not using proper C++ templates though, as I wrote this before they were standard. I have no plans to implement algebraic numbers in eclib! Better would be to gradually transfer more of eclib to FLINT (e.g. all the elliptic curve classes, methods and functions.

templates were already standard 25 years ago, e.g. CGAL was using them back then already. Another question is how hard they were to use :-)
I got an RSI debugging them...

But now C++ is basically a different language, and templates are easier to use.

I am going to replace eclib version 20241112 with a new version with three extra tiny commits, and I hope that will deal with the hold-up here. (1) as @tornaria suggested JohnCremona/eclib#81, revert to the older version of modrat to avoind the 32-bit test failure; (2) as reported by @thierry-FreeBSD JohnCremona/eclib#83 (3) ding an #include to keep FLINT happy.